The PHP check error, I think, is due to the fact that in some of the 2.1 source code the year is still 2024...

I've been running this on my prod forum since about 1/2/25, and since then I have not seen crazy spikes in CPU or 'most online' stats.

I still have this running on my production forum, and the results are still excellent. Still no significant spikes in CPU or most online.

Even more surprising... Interest in our board jumps significantly upon certain product launches. We had to do a massive board index restructure to fold in the new products, and legit user visits have been sustained pretty high since the product announcement.

In the past, either of these circumstances, either the board restructure or the spike in interest due to a product launch, would have caused significant CPU spikes for a few weeks. We are seeing MUCH improved behavior...

Notes on the recent commits:

With cookies disabled, & PHPSESSID removed from URLs:

• Captchas did not work - the image was missing on the screens. This affected guest posts, guest searches, & new user registrations.
• Even when captchas were not required, guest posts did not work & registrations did not work - they errored out on session errors.
• Guest searches work fine if captcha is not required.

Note that if you went to the action under these circumstances, the screen was incomplete - it was missing the capcha image. Since it can look quite odd/confusing, partially painting the screen of a function they can't use, it is a little tidier to just not let them go there.

Note also that the login logic needed a little tweaking - checking the session before loading the theme made it difficult to provide a meaningful 'check your cookies' error upon login. A workaround is proposed here.

I want to add that, I'm also running without PHPSESSID on my live forum for about ~15 months.

Here are the changes I have:

 Sources/QueryString.php | 3 +++
 Sources/Session.php     | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Sources/QueryString.php b/Sources/QueryString.php
index 70588db27..74c6e3317 100644
--- a/Sources/QueryString.php
+++ b/Sources/QueryString.php
@@ -652,6 +652,9 @@ function ob_sessrewrite($buffer)
 	if ($scripturl == '' || !defined('SID'))
 		return $buffer;
 
+	// Please don't add session IDs to urls.
+	return $buffer;
+
 	// Do nothing if the session is cookied, or they are a crawler - guests are caught by redirectexit().  This doesn't work below PHP 4.3.0, because it makes the output buffer bigger.
 	// @todo smflib
 	if (empty($_COOKIE) && SID != '' && !isBrowser('possibly_robot'))
diff --git a/Sources/Session.php b/Sources/Session.php
index 5237af0b5..d84dcb083 100644
--- a/Sources/Session.php
+++ b/Sources/Session.php
@@ -29,7 +29,7 @@ function loadSession()
 
 	// Attempt to change a few PHP settings.
 	@ini_set('session.use_cookies', true);
-	@ini_set('session.use_only_cookies', false);
+	@ini_set('session.use_only_cookies', true);
 	@ini_set('url_rewriter.tags', '');
 	@ini_set('session.use_trans_sid', false);
 	@ini_set('arg_separator.output', '&');

Also I want to add that, users without cookies are so rare in fact that I've yet to heard a single feedback from someone about the forum is broken.

As for the reason why I made this change, because I removed the index.php from my $scripturl, and this breaks the very first load on the page. I looked what ob_sessrewrite function did, and decided it's such an edge case that it's probably not needed for regular users.

Also I want to add that, users without cookies are so rare in fact that I've yet to heard a single feedback from someone about the forum is broken

Yep. Same here.

I suggested this PR to our staff who implemented the changes in response to recent crawler/bot wave but ended up reverting. While there was a minor reduction in processor spikes with the patch, the staff received complaints that the forum had broken from various privacy minded members. We're looking at some kind of middle ground where cookie-free users can still use the forum but cookie-less crawlers don't end up mass generating sessions. We're reworking it to only generate a session if the user agent performs an action which requires a session (login, registration, guest captcha). That way bots loading up seemingly random pages on the forum from a crawl list don't generate sessions.

If you have analytic tools, check to see if your rise in traffic is AI-related. AI bots do not respect robots.txt or other normal bot-related optimizations, and the only way to counter them is with firewalls.

I suggested this PR to our staff who implemented the changes in response to recent crawler/bot wave but ended up reverting. While there was a minor reduction in processor spikes with the patch, the staff received complaints that the forum had broken from various privacy minded members. We're looking at some kind of middle ground where cookie-free users can still use the forum but cookie-less crawlers don't end up mass generating sessions. We're reworking it to only generate a session if the user agent performs an action which requires a session (login, registration, guest captcha). That way bots loading up seemingly random pages on the forum from a crawl list don't generate sessions.

Thanks for the feedback, helpful.

When folks said the forum seemed broken, what functions did not work, exactly? I believe the only functions that are no longer supported are:

• Guests posts with cookies disallowed
• Search verifications with cookies disallowed (search works OK without verification)
• New user registrations with cookies disallowed (not really a loss, because they can't login with cookies disallowed)

Folks with cookies disabled could never login; this PR doesn't change that.

A few other things to keep in mind:

• You cannot distinguish bots from users via useragent. Most of the problematic bots I see today use useragents that mimic users on browsers.
• GET/POST sessions are deprecated in php8.4 & are gone by php9.0. I.e., this is coming one way or another. This PR prepares SMF for this eventuality.
• The reason for deprecating url sessions is it is no longer considered safe/good practice. So... without a cookie... how are you going to lookup the session?

Another before & after, still looking good. Before, the forum spent 40%+ of its days at or above 40 mins CPU. Monthly, it would exceed 100+ mins for days on end. With this PR, it has reached 40 mins only twice in the last 3 months, and has not exceeded 41 mins in that timeframe.

I don't know why this still says 'changes requested', I think I addressed all of them.

I found one more limitation: a guest with cookies disallowed cannot view who liked a post. That passes a session via URL as well.

I'll tweak this over the next few days when I have time.

The above issue was addressed. I kept the text, e.g., "2 people like this", but it is no longer a link.

@sbulen Is this PR mergable yet or are you still expecting changes?

@jdarwood007 - I am OK with merging; I've had this on my site all year.

The comment above from @Doyeip gives me a bit of concern though. There may be ramifications to serious privacy-minded users. OTOH, from a PHP perspective, this is coming no matter what. And passing session by URL is clearly not a good thing to do... Still, folks are folks, & we may see a bit of pushback from those who disable cookies, e.g., TOR-browser-adjacent folks.

I would almost propose a service worker to retain the "session" token, but bots use real rendering engines and JavaScript processing just like a normal browser, and would continue to be able to pass on. But it would mean they would have to register the service worker to continue a normal browsing session, which seems like a step up from what I would expect more harmful bots to do.